The Superstruct Manifesto: A Survival Guide for Founders Who Depend on Devs to Get Things Done by David Guttman

Author:David Guttman [Guttman, David]
Language: eng
Format: epub
ISBN: 9798987846612

You do not want $100 solutions to $5 problems.

Estimates help align these incentives.

Estimates are also valuable midway through the project. They give you a good timeline of when to check in on progress. When a project goes off the rails, the sooner you know about it, the better.

Without an estimate, you can only do periodic or milestone progress updates. With an estimate, you can check in at the 25%, 50%, 75%, and 90% marks. At these checkpoints, you should be testing the dev’s confidence that everything is going according to plan. They should be growing more certain that they will hit the target ship date as time goes on. If they are less confident, that’s a sign that you should dig in further or possibly intervene.

Pay particular attention to how the dev is acting at the 75% and 90% checkpoints. There’s a reason why the last 10% of most projects takes 90% of the time. This is where you’ll find out that your dev has been avoiding all the uncomfortable unknowns, a product manager has been moving the goalposts, or that your dev has to drive their hamster to the psychiatrist an hour away each day and doesn’t have as much time as they thought. The sooner you uncover these issues, the better—and you’ll want to cut scope, add someone else to the project, and/or remove someone from the project ASAP.

To get the most out of these benefits, you’ll want your dev’s estimates to be at least somewhat aligned with reality. To be clear, you do not need estimates to be exact to be useful. Estimates are just a type of measurement. Measurements are observations that reduce uncertainty. We can’t eliminate uncertainty, and there are diminishing returns to precision.

The best way to get good estimates is to make this clear to your devs. They are neither expected to provide estimates down to the millisecond nor are they expected to ship right on the dot. In my experience, you’re doing well if most estimates are within 15%. You’re going to have some projects be off by 50% or more. That’s life, but don’t let those become common.

I’ve seen managers try to “reduce developer stress” by making it clear that wrong estimates were not the fault of any particular dev, but instead are the fault of the entire team. Managers like this will run planning poker sessions, take an average of the estimates, and when that estimate is invariably wrong, shrug it off and tell the dev they did a great job. This provides no incentive to any dev to improve their estimates or to try to hit the targets. Diffusing responsibility over the whole team is a bad idea.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.